Network management system

ABSTRACT

A network management system for configurating and reading data and states of several network elements, such as telephone exchanges, of a telecommunication network by giving the network elements commands according to their internal command language when at least some of the network elements of the telecommunication network have mutually different internal command languages includes a memory for storing parameters describing the command language of each network element, a generator for generating service requests (Rq) in a network element-independent format, a converter (21, 22, 23) for converting the network element independent service requests into commands according to the command language of the network element which is the target of service by using parameters describing the command language of the network element, and a sender for sending the generated commands to the network element which is the target of service. The network management updates the parameter files automatically by giving the network elements a specific command which reads the internal data structures, such as syntactic, semantic and user help data, of any other internal command or command response of the network element.

BACKGROUND OF THE INVENTION

The invention relates to a network management system for configuratingand reading data and states of several network elements, such astelephone exchanges, of a telecommunication network by giving thenetwork elements commands according to their internal command languagewhen at least some of the network elements of the telecommunicationnetwork have mutually different internal command languages, the systemcomprising memory means for storing parameters describing the commandlanguage of each network element, means for generating service requestsin a network element independent format, conversion means for convertingthe network element independent service requests into commands accordingto the command language of the network element which is the target ofservice by means of parameters describing the command language of thenetwork element, means for sending the generated commands to the networkelement which is the target of service, means for receiving commandresponses sent by the network element which is the target of service andfor converting them into a network element independent format.

Modern telecommunication networks comprise a large number of differentkinds of network elements, such as telephone exchanges, transmissionsystems, etc., the states and data of which the network operator mustread and change daily. Typical examples of recurrent changes aredeletion, addition or modification of subscribers, and different changesin routing for instance when a network element is overloaded. Theexchanges are controlled either by remote control or locally byin-putting commands for configurating their data, changing their states,etc. A modern telephone exchange may have several hundreds of differentcommands by which exchange specific data can be modified. On the otherhand, many kinds of data are received from the exchanges: alarm outputs,measurement reports, charging data.

There have been attempts to develop network management systems which ina centralized manner would carry out the configuration and reading ofdata and states of different network elements in a telecommunicationnetwork. At present, the standardization organizations (e.g. ETSI,CCITT) are specifying the management standards for telephone exchangesand all network elements in general. Such a concept is called a TMN(Telecommunication Management Network). Standardized interfaces betweenthe control system and the network elements are of crucial importance instandardization. However, such new standardized solutions will not beavailable for a long time and will require planning with respect to allnetwork elements, wherefore it takes a long time before they are usedfor controlling all the network elements. Until then, the networkmanagement systems to be implemented must communicate with existingnetwork elements in a manner which they understand in their internalcommand languages, which in telephone exchanges, for example, aremanufacturer and type specific. New versions of command languages arecreated with new system generations of different telephone exchanges ofthe same manufacturer and with new software versions. This poses greatproblems for outside network management systems which are completelyindependent of the network elements but which should, however, masterthe different command languages and their versions. Network managementshould further be capable of adapting to a new command language whenevera new network element is introduced to the telecommunication network. Atits worst, this results in that the operator of the network managementsystem must continually modify his network management software in orderto meet this requirement. The network management becomes more and moredifficult when the number of network elements increases.

U.S. Pat. No. 4,782,506 discloses a network management system whichoperates one or more exchanges connected thereto. The management systemis provided with correlation memories, in which there are stored thestructural data of both commands and command responses of differentexchanges. In addition, the formal representations of differentoperations are stored in SDL/PR format in the correlation memories; infact, these representations describe the management operations indetail, i.e. how the different operations of the exchange are performedstep by step, command by command. These data have contributed to networkmanagement that is to a great extent independent of the type of thesystem to be controlled. The operator gives commands in a universallyapplicable formal format, from which they are converted into the commandlanguage of the exchange. The structural representations of the commandsand command responses of all exchanges are written and updated manuallythrough a specific editing console in relational memories.

In practice, however, network management systems manage very largetelecommunication networks, which may comprise dozens, even hundreds ofexchanges. The exchanges are continuously modified, and new exchangesare connected under the management. Software is updated, and often thechanges can also be seen in the interface with the management system.The syntax of commands may change: new parameters are added, new fieldsappear in the command responses, or completely new commands may begenerated. In order for the management system to function appropriately,it is crucial at the same time to keep the correlation memories up todate. Even small modifications of command responses, in particular, maylead to total malfunctions. It is nevertheless problematic to keep thecorrelation memories up to date. It is very laborious to perform thistask for instance by manual programming, and errors are easily made, as,e.g., modern telephone exchanges may include hundreds of differentcommands.

SUMMARY OF THE INVENTION

The object of the invention is to provide a network management system inwhich the above-mentioned drawback can be decisively remedied.

This is achieved with a network management system as described in theintroductory portion, this system being characterized according to theinvention in that the internal commands of at least one network elementinclude a reading command for reading the internal data structures, suchas syntactic, semantic and user help data, of any other internal commandor command response of the network element, and that by means of thereading command the network management system automatically updates theparameters which describe the command language of the network elementand are stored in the memory means.

In the network management system according to the invention, the user,such as the network operator, can program his or her daily routines intoservices which are easy to use and independent of the network elements.The system according to the invention converts the network elementindependent tasks of these services or service requests automaticallyinto commands in the command language of the network element which isthe target of service, using parameters that are stored in the networkmanagement system and describe the command language of the networkelement concerned. The parameters describing the command language ofeach network element under the network management system are stored in aseparate file. Correspondingly, the network management system analyzesnetwork element-specific command responses and converts them into anetwork element-independent format.

The invention enables the user to start all the network managementroutines in the same way without having to know what command languagethe network element that is the target of the service routine uses orwithout having to know the details of the command language. The userapplication programs form general, network element independent servicerequests which contain the necessary control parameters, such as thetarget of service and the data to be modified. These general servicerequests are converted into network element-specific tasks containing anumber of network element-dependent command requests. By means of thesenetwork element-specific command requests and the stored parametersdescribing the command language it is possible to form the commands of acertain network element necessary for carrying out the task. The controlparameters given in the network element-independent service request aredisposed in these commands in the manner required by the structure ofthe command language. Each network element-independent general commandrequest comprises, for each network element, a separate networkelement-specific or command language-specific task with commandrequests. When a new network element with a new command language isbrought under the network management system, the user himself or herselfmay program the parameter file describing the command language and thenetwork element-dependent tasks (task macros) into the command languagein question for the network element-independent service requestsdesired. Once the task macros have been formed, the user no longer hasto know anything about the command language used by the network elementconcerned. In the network management system of the invention, additionof new command languages or modification of the old ones brings aboutchanges only on the lowest level of hierarchy in the generation ofcommand languages without requiring any other modifications in thenetwork management system; it can therefore be easily carried out by theuser himself or herself.

It is very laborious to program the parameter file describing theinternal command language of a network element, for instance manually,and errors are easily made, as, e.g., modern telephone exchanges mayinclude hundreds of different commands. According to the invention, theinternal commands of a network element include a specific readingcommand for reading the internal information structures--such assyntactic, semantic and user help data--of any other internal command orcommand response of the network element. Using this command, the usercan automatically control the desired network element from the networkmanagement system, read the parameters describing the command languageof the network element, and update them automatically in thecorresponding file. Alternatively, the same reading command renders itpossible to read these parameters temporarily to another memory, e.g. amemory disk, by means of which they can be easily transmitted to a fileof the network management system. This arrangement expedites andfacilitates the formation of parameter files considerably, andeliminates errors that are easily made in the formation.

BRIEF DESCRIPTION OF THE DRAWING

In the following, the invention will be described in more detail bymeans of embodiments and with reference to the accompanying drawing, inwhich:

FIG. 1 is a functional block diagram of the network management system ofthe invention, and

FIG. 2 is a functional block diagram of the command generator includedin the communications server of FIG. 1.

DETAILED DESCRIPTION

The architecture and main operations of the network management system ofthe invention, and also its features pertaining to user application aredescribed in the following with reference to the block diagram ofFIG. 1. The network management system set forth as an example is adistributed system which utilizes a local area network (LAN) and can beflexibly modified and expanded. However, the network management systemof the invention can naturally also be implemented with other systemarchitectures. In FIG. 1, the network management system comprises acommunications server 1, a database server, and a plurality of workstations 10 connected to a local area network 3. The physicalconstruction of the local area network may be, e.g., Ethernet, and theprotocol used therein may be, e.g., TCP/IP. Network management tasks,e.g., for monitoring the configuration, alarms and performance ofnetwork elements, such as public telephone exchanges or mobileexchanges, are carried out in application programmes run in the workstations 10 and the servers 1 and 2, for example in open UNIXenvironment. The database server 2 forms an SQL interface 10 with thenetwork database 4 for the application programs for storing andsearching for network management data. The database 4 contains networkconfiguration management data, describing all the network elements, andalso possible performance data, billing information, etc.

The communications server 1 forms a gateway between the networkmanagement applications and the network elements to be managed. Thesenetwork elements of the telecommunication system 11 may include e.g.Nokia Telecommunications DX200 switching system 5, LM Ericsson AXEswitching system 6, and Siemens EWSD switching system 7 with theircontrol units, as well as circuit and signalling elements in the PSTNand the CCS7 network. The abbreviations DX200, AXE and EWSD will be usedhereafter for these network elements. The communications server 1 mayhave X.25 or Ethernet-based OSI connections to the operation andmaintenance center (OMC) for DX200 exchanges, the OMC constituting thehighest level of centralized management of the entire network of DX200exchanges. There may also be a connection directly to a DX200 exchange.The connections between the communications server 1, and the AXE andEWSD exchanges 6, 7 utilize the AXE and EWSD system-specifictransmission protocols. The communications server 1 provides three kindsof interfaces: 1) MML (Man-Machine Language) commands or task requeststo network elements, 2) file transfer services for transferring filesfrom network elements, and 3) reception of spontaneous responses fromnetwork elements.

In principle, different manufacturers have tried to implement thecommand languages of their network elements in a command languagedefined by the CCITT recommendations Z.301-Z.341. However, as thedefinitions of the syntactic and semantic structures of this commandlanguage are vague, different manufacturers can choose very differentways of approaching the subject and end up with very different kinds oflanguages. Moreover, there may be significant differences between thecommand languages of different system generations of even the samemanufacturer. The network management system and the communicationsserver 1 should be capable of communicating with each network element inits own command language. In the system of the invention this has beenimplemented in such a manner that the users may program all their dailyroutines into services which are easy to use. The services are networkelement-independent and contain a suitable user interface with menus anduser help texts. The communications server transforms the networkelement-independent service requests it has received automatically intocommands according to the internal command language of the networkelement that is the target of service by means of software which willhereafter be called a command generator. In other words, the commandgenerator is, in general, software which generates from general andnetwork element-independent service requests the MML commands necessaryfor performing a task for controlling a certain network element.

The structure and operation of the command generator included in thecommunications server 1 will be described with reference to thefunctional block diagram of FIG. 2. The command generator set forth asan example is divided into four functional blocks: verification block21, logic block 22, command generation block 23, and response analysisblock 24. In addition, FIG. 2 shows a memory 25 for storing networkelement specific parameters describing the command language, and amemory 26 for storing representations of network element specificresponses.

The verification block 21 verifies the rationality of the controlparameters occurring in the service request Rq from the applicationprogram requesting the service, and the state(s) of the networkelement(s) 5, 6, 7 from the network database 4. In addition to this, theverification block 21, by means of link establishment means (not shown)included in the communications server 1, establishes links to thenetwork element(s) necessary for carrying out the service request,records the received service request Rq as such in a logic file, andtransforms the service request, if necessary. The interface between theverification block 21 and the logic block 22 is preferably selected tocorrespond to the telecommunications interface of the future TMNrecommendations Q3 of the CCITT. The future network elements with a TMNinterface can thereby be controlled directly through the verificationblock 21.

The verified service request Rq is supplied from the verification block21 to the logic block 22, which forms a task containing several networkelement-dependent MML command requests from a general networkelement-independent service request Rq. For each networkelement-independent service and service request there exists a separatetask with command requests for each network element or command languagerequired. The task(s) required in each case is (are) selected andstarted on the basis of the target parameter which is included in thenetwork element-independent service request and which indicates thenetwork element(s) to which the service is directed.

The network element dependent command requests formed by the logic block22 are supplied to the command generation block 23, which from MMLcommand requests forms the final MML commands according to the internalcommand language of the network element that is the target of service bymeans of parameters 25 describing the internal command language of thenetwork element. The parameters may contain, on the one hand, datarelating to the command, and, on the other hand, data relating to thesyntax of the command. The control parameters given in the servicerequest Rq are included in the commands generated in block 23 in themanner required by the command language in question. From the commandgeneration block 23, the network element-specific commands are suppliedto the network element concerned.

In its responses, the network element that is the target of the servicerequest employs network element-specific command responses, whichinclude data relating to the network element. The response analysisblock 24 of the command generator receives the network element-specificresponses and converts them into a network element independent formatwhich the logic block 22 understands, using the system specificrepresentations of command responses stored in the files 26. By means ofthe command responses it is possible to control, for example, the stateautomaton created by the task started by the service request Rq in thelogic block. The sending of the first command of the task, for example,may set the state automaton in a certain state where it waits for aresponse that the command has been completed. When the state automatonreceives information from the response analysis block 24 to the effectthat this has received a command response indicating that the commandhas been completed, the state automaton proceeds to the following state,in which it sends the following command. Network element-independentcommand responses can be further transmitted from the logic block 22 tothe verification block 21, and this way as responses Re to applicationprograms.

According to the invention, the internal commands of a network element,such as an exchange, comprise a specific reading command for reading theinternal data structures--such as syntactic, semantic and user helpdata--of any other internal command or command response of the networkelement. Using this command, the user may automatically control thedesired network element from the network management system, read theparameters describing the command language of the network element, andautomatically update them in the corresponding file. The reading commandmay be given directly from the work station, or it may be stored inparameter files and started by a network element independent command asdescribed above.

An example of application programs utilizing a command generator in anetwork management system of the invention is management of subscriberconnections in a telephone exchange. The following service requests, forexample, may be associated with this application: creation, deletion,closing or opening of a connection, reading of facilities or chargingcounters of a connection, change of location of a connection, change oftelephone number of a connection.

The accompanying drawings and the description relating thereto areintended merely to illustrate the present invention. In its details thenetwork management system of the invention may vary within the scope ofthe appended claims.

I claim:
 1. A telecommunications network, comprising:a plurality ofnetwork elements having internal command languages, said internalcommand languages being mutually different in at least two of saidnetwork elements, and at least one of said network elements beingprovided with a reading command for reading internal data structures ofany internal command or command response of said at least one of saidnetwork elements, a network management system for configuration andreading data or states of said network elements, said systemcomprising:memory for storing parameters describing the respective saidinternal command language of each of said network elements, means forgenerating service requests in a network-independent format, conversionmeans for converting said service requests in a network independentformat into commands according to the respective said internal commandlanguage of a respective said network element which is a target ofservice, by means of parameters describing the respective said internalcommand language of said respective network element, means for sendingsaid converted commands to said respective network element which is thetarget of service, and means for receiving command responses sent by therespective said network element which is the target of service, and forconverting said command responses into said network-independent format;and said network management system utilizes said reading command toupdate said parameters which describe the respective said internalcommand language of said at least one network element in said memory ofsaid network management system.
 2. A telecommunications networkaccording to claim 1, wherein said conversion means of said networkmanagement system comprises:command request means for converting anetwork element-independent service request into a plurality of networkelement-dependent command requests, and command generation means forgenerating network element-dependent commands as a response to saidcommand requests received from said command request means via saidparameters describing the respective said internal command language ofsaid respective network element.
 3. A telecommunications networkaccording to claim 2, wherein said conversion means of said networkmanagement system comprises:means for verifying said networkelement-independent service request, and means for initiatingestablishment of a link to said respective network element which is thetarget of service.
 4. A telecommunications network according to claim 1,wherein:said internal data structures of said internal command languagesof said network elements are substantially in compliance with CCITTrecommendations Z.301-Z.341.
 5. A telecommunications network accordingto claim 1, wherein:said means for generating service requests compriseuser application programs.
 6. A telecommunications network according toclaim 5, wherein:said user application programs comprise subscriber andline-managing applications for at least one of creating, deleting,closing, opening, and modifying subscriber connections.
 7. Atelecommunications network according to claim 1, wherein:at least someof said network elements are telephone exchanges.
 8. Atelecommunications network according to claim 1, wherein:at least someof said internal data structures are ones selected from the groupconsisting of syntactic data, semantic data and user help data.
 9. Atelecommunications network, comprising:a plurality of network elementshaving internal command languages, said internal command languages beingmutually different in at least two of said network elements, and atleast one of said network elements being provided with a reading commandfor reading internal data structures of any other internal command orcommand response in the respective said internal command language of therespective said at least one network element; a network management forconfiguration and reading data or states of said network elements, andsystem comprising memory for storing parameters describing therespective said internal command language of each of said networkelements, said network management system utilizes said reading commandto update said parameters which describe the respective said internalcommand language of said at least one network element in said memory ofsaid network management system.
 10. A telecommunications networkaccording to claim 9, wherein:at least some of said network elements aretelephone exchanges.
 11. A telecommunications network of claim 9,wherein:at least some of said internal data structures are ones selectedfrom the group consisting of syntactic data and semantic data.